1. Field of the Invention
The present invention relates to the field of Web portals and portlet handling, and, more particularly, to updating portlet interface controls by updating a hidden version of the control and then switching the hidden version with a presented version, thereby reducing flicker and other potential updating problems.
2. Description of the Related Art
A Web portal is a Web site or service that offers a broad array of resources and information, such as e-mail, search engines, advertising, user-specific reports, personalized contact and task management functions, customized news feeds, local weather, and the like. A Web portal can include multiple Web portlets. Each Web portlet can be a reusable Web component that displays information to portal users from a designated source, which can be different from the source that provides information for the portal. An arrangement of portlets within a portal, a presentation of information within the portal, the responsiveness of this presentation, and other user perceived factors all contribute to the user experience of the portal.
A user's experience is often enhanced when interface controls, such as dials, charts, tickers, and the like, are used to present data. This is especially true when a user can customize the controls to provide alerts of important situations and/or can select particular controls to drill down information contained therein. Accordingly, the controls within portlets can present real-time updates to a user. The user can quickly digest the information conveyed by the controls and can detect important anomalies and respond in an appropriate fashion.
Unfortunately, conventional methods for updating portlet information can result in numerous substantial problems, such as flicker. Flicker often occurs when multiples of frequently updated interface controls exist in close proximity, each being associated with its own portlet. Each control requires continuous data updates (such as every 1 to 10 seconds), update processing, and a visual refreshing of the control to show the data updates. The frequency of control updates and related processes is typically independent of other control updates for other portlets. Additionally, each control typically consists of multiple elements, such as chart bars and values and/or dial positions, where the visual elements can be processed in sequence as element specific updates are received. When update and processing delays occur, a portion of the control elements are sometimes updated but a different portion of the control elements are not, resulting in a confusing visual experience.
Problems are escalated as the number of portlets increases, since a single and independent process is typically utilized on behalf of each portlet. Serialization of data requests (associated with different processes) can occur if the requests are made within the same time frame relative to the amount of time necessary to refresh an interface control. A manifestation of this problem is that the visual controls within portlets appear to be stalled from time to time and one or more updates can be skipped as the control refreshing is not performed within a refresh rate period established for the control. Instead of a relatively smooth refreshing of controls, the controls appear to “jump” from one step to another, which results in a distracting and non-appealing user experience. In extreme cases, data update problems among the portlets can overload a system, causing a portlet or Web browser to lock up completely.
FIG. 1 shows the basic interactions executed to enable a client device to utilize one or more data sources linked to one or more portlets to produce a user experience for the portal. From FIG. 1 it can be readily understood that portlet updates occur independent of each other with each portlet constantly polling data sources for updates. The constant polling for updates and receiving of responses that occur on a portlet-by-portlet basis can quickly overload a system or communication infrastructure to an extent that data updates are delayed, flickering occurs, portlets appear to stall, and lockups occur, thus detracting from the resultant user experience of the portal. While FIG. 1 assumes the data source used by the portlets is part of a Service Oriented Architecture (SOA) 112, the portlet communication pattern shown in FIG. 1 applies to portlets-data source communications in general and is not limited to a particular software architecture, such as SOA 112.
As shown, the client 102 portlets 106 and 108 of FIG. 1 can utilize JAVASCRIPTS to request that the portlets 106-108 be refreshed. The portal server 104 can create a process to handle retrieving data to update the portal 104. The portlets 106-108 can retrieve data from various components of the SOA 112. Each portlet 106-108 independently follows an equivalent update process. For example, a client 102 can request that information in a selected portal 104 to be refreshed. The portal 104 will render interface controls in portlet 106 or 108. This rendering can require data values be obtained from a portlet process, which can require information be obtained from the SOA 112. The SOA 112 sends responses back to the common portlet process, to the requesting portlet 106 or 108, which sends data to the portal 104, which properly renders/presents the updated information upon client 102.